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ABSTRACT 


This  thesis  explores  the  creation  of  a  conceptual  design  for  a  database  that  would 
assist  any  Naval  shore  command  with  its  internal  information  needs.  The  database  is 
intended  to  be  a  multi-user  database  accessed  via  a  local  area  network  (LAN).  The  thesis 
examines  the  administration  and  information  needs  of  the  command  as  an  interrelated 
whole  rather  than  as  individual  division  and  departments. 

As  the  Navy  changes  to  meet  different  world  situations,  the  need  for  administrative 
and  management  information  within  a  shore  command  has  increased.  Most  shore 
commands  have  attempted  to  meet  this  need  with  single-user  relational  databases.  Often 
these  databases  are  poorly  designed  and  incorrectly  implemented. 

This  project  uses  the  enhanced  entity  relationship  model  to  create  a  conceptual 
design  for  an  administrative  database.  This  basic  model  can  be  customized  to  fit  the 
needs  of  a  shore  command.  Fleet  Numerical  Oceanography  Center,  Monterey,  CA  was 
used  to  represent  a  typical  mid-sized  shore  command  to  develop  the  basic  model  and 
prototype. 
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I.  INTRODUCTION 


This  thesis  explores  the  creation  of  a  conceptual  design  for  a  multi-user  relational 
database  that  would  serve  any  Naval  shore  command  with  its  internal  information  needs 
via  a  local  area  network.  The  thesis  examines  the  administration  and  information  needs 
of  the  command  as  an  interrelated  whole  rather  than  individual  division  and  departments. 

A.  BACKGROUND 

1.  Historical  Perspective 

The  Navy  has  been  using  computers  and  developing  applications  for  many 
years  to  support  its  operational  mission.  There  are  a  variety  of  computers  and  software 
used  in  weapons  systems,  simulators,  accounting  and  payroll.  Traditionally  the  internal 
administration  and  management  of  a  command,  however,  have  received  very  little 
automated  data  processing  (ADP)  support.  These  internal  management  functions 
consume  a  large  portion  of  a  manager’s  time.  The  officers  and  senior  civil  service 
personnel  spend  valuable  hours  tracking  down  such  things  as  purchase  requests  or 
personnel  information. 

When  the  Navy’s  Z-248  micro-computer  contract  became  available,  personal 
computers  and  commercial  off-the-shelf  software  (COTS)  began  appearing  throughout 
shore  commands.  Managers  immediately  recognized  the  potential  of  word  processing  on 
microcomputers  to  relieve  the  overwhelming  paperwork  encountered  each  day.  Navy 
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personnel  began  developing  small  applications  beyond  word  processing  by  taking 
advantage  of  COTS  spreadsheets,  graphic  programs  and  database  management  systems 
available  from  the  Z-248  contract. 

2.  Hie  Problem 

One  piece  of  software  that  was  purchased  with  the  Z-248  PC  contract  was  a 
relational  database  management  software  package  [Ref.  l:pp.  135-148].  Numerous 
databases  were  developed  by  personnel  who  had  little  or  no  expertise  with  database 
design.  Examination  of  these  databases  shows  there  is  very  little  design  or  user 
documentation  available.  The  databases  are  not  normalized  [Ref.  l:p.373].  Many  users 
feel  the  applications  are  awkward  to  use  and  inaccurate.  Often,  only  the  developer  of 
the  database  can  actually  use  the  application.  While  information  may  be  lost  each  time 
a  personnel  turnover  occurs,  these  databases  fill  an  immediate  need  for  more  effective 
control  of  information  within  the  command. 

Personnel  in  the  command  find  these  databases  frustrating.  The  databases  are 
rarely  accurate  and  require  too  much  effort  to  maintain.  Check-in/check-out  procedures 
illustrate  the  number  of  duplicate  databa^s  maintained  within  the  command.  When  new 
sailors  report  to  the  command,  they  are  given  a  check-in  sheet  with  10  to  15  different 
individuals  or  divisions  they  must  visit.  At  each  location  the  sailor  repeats  personal  data. 
For  example,  names,  social  security  numbers  and  home  phone  numbers  might  be  retained 
by  the  administration  officer,  the  department  head,  the  division  officer,  the  security 
officer,  the  master  chief  petty  officer  of  the  command  and  the  command  duty  officer. 
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At  most  of  these  sites  a  database  residing  on  a  personal  computer  is  u^>ed  to  record  tiw 
sailor’s  arrival. 

Upon  the  sailor’s  departure  the  process  is  reversed,  except  now  each  person 
on  the  check-out  sheet  attempts  to  determine  if  the  individual  has  any  outstanding  acticm 
items  requiring  clearance  before  the  sailor’s  departure.  Have  they  returned  all 
government  property?  Have  they  turned  in  their  access  badges?  Each  division  then 
modifies  their  database  to  record  the  individual’s  departure. 

These  processes  make  check-in  and  check-out  one  of  the  most  dreaded  aspects 
of  a  transfer.  Because  check-in  and  check-out  are  so  frustrating,  individuals  often 
attempt  to  circumvent  the  process.  A  sailor  visits  only  those  sites  deemed  in  their  best 
interest  to  notify  of  their  arrival  or  departure.  It  is  not  unusual  for  different  divisions  in 
a  command  to  have  widely  different  databases  concerning  the  personnel  assigned  to  the 
command. 

A  sophisticated  command  recognizes  the  problem  of  unsychronized  databases 
and  creates  elaborate  administrative  procedures  to  ensure  the  critical  databases  are  kept 
synchronized.  Data  may  be  transferred  by  paper  report  or  on  floppy  disk  between  the 
divisions.  While  this  eliminates  the  problem  of  unsynchronized  data,  the  data  is  usually 
late  and  the  intricate  administrative  procedures  are  too  complex  to  be  performed 
correctly. 

We  propose  that  one  multi-user  database  be  maintained  at  a  command  and 
each  of  the  various  departments  and  divisions  have  access  to  the  information  they  need. 
This  was  impossible  a  few  years  ago  since  most  shore  commands  did  not  have  any  type 
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of  computer  network  accessible  by  different  people  in  different  locations.  If  a  command 
had  a  multi-user  computer  network  it’s  primary  purpose  was  certainly  not  for  the 
administration  and  management  of  the  command.  Now,  the  availability  of  personal 
computers,  LAN  technology  and  inexpensive  multi-user  relational  database  software 
make  this  proposal  feasible. 

3.  Local  Area  Networks 

Local  area  networks  combine  the  benefits  of  a  personal  computer  with  those 
of  a  multi-user  system.  A  LAN  allows  users  to  communicate  with  one  another  and 
access  a  multi-user  database.  Data  can  be  transferred  to  an  individual’s  personal 
computer  for  further  manipulation.  A  LAN  also  allows  expensive  hardware  and  software 
to  be  shared  among  many  users. 

As  LAN  technology  became  less  expensive  it  became  more  commonplace. 
Many  large  and  mid-sized  Naval  shore  commands  have  invested  in  LANs,  originally  to 
share  expensive  resources;  they  are  now  beginning  to  see  the  benefits  of  using  the  LAN 
to  quickly  develop  shared  relational  databases.  There  are  many  inexpensive  COTS 
database  management  packages  on  the  market  to  help  managers  build  relational  databases 
which  meet  their  requirements. 

B.  RESEARCH  QUESTIONS 

The  purpose  of  this  su  dy  is  to  answer  three  research  questions  concerning  the 
design  and  implementation  of  a  Naval  shore  command  administrative  and  managemmt 
relational  database; 
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•  Which  management  functions  of  a  Naval  shore  command  are  suited  for 
implementation  in  a  multi-user,  relational  database? 

•  Can  a  generic,  conceptual  database  model  be  designed  to  meet  the  needs  of  any 
Naval  shore  command? 

•  What  are  the  potential  benefits  of  implementing  such  a  database? 

C.  METHODOLX)GY 

The  Fleet  Numerical  Oceanography  Center  (FLENUMOCEANCEN)  in  Monterey, 
CA  volunteered  to  serve  as  a  test-bed  for  this  research.  FLENUMOCEANCEN  is  a 
command  of  approximately  350  military  and  civil  service  employees.  There  are  also  a 
number  of  contractors  that  work  at  FLENUMOCEANCEN  facilities. 
FLENUMOCEANCEN  has  a  traditional  chain  of  command  structure  with  a  commanding 
officer  (CO),  an  executive  officer  (XO),  department  heads  and  division  officers. 

Information  for  this  thesis  was  collected  by  interviewing  all  department  heads, 
many  division  officers,  and  personnel  currently  responsible  for  maintaining  or  updating 
the  command’s  existing  databases.  Existing  databases  were  examined  to  determine  the 
merits  and  demerits  of  the  data  maintained.  No  attempt  was  made  to  convert  the 
application  code  of  their  systems. 

Chapter  II  examines  the  data  and  functional  requirements  of  this  project.  Chapter 
III  contains  a  brief  discussion  of  the  conceptual  design  model  used  for  this  project  and 
Chapter  IV  discusses  the  model  developed  during  this  project.  Chapter  V  considers  some 
security  and  administrative  requirements  for  implementation  of  a  database.  Chapter  VI 
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reviews  the  prototype  database  developed  for  FLENUMOCEANCEN  and  Chapter  VII 
concludes  this  thesis. 
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II.  DATA  REQUIREMENTS 


This  chapter  discusses  the  administrative  information  needs  at 
FLENUMOCEANCEN.  Interviews  and  existing  single-user  database  systems  were  used 
to  help  categorize  the  information  needs.  The  personnel  also  discussed  their  concerns 
regarding  the  implementation  of  a  multi-user  database. 

A.  INFORMATION  NEEDS 
1.  The  Managers 

The  managers  at  FLENUMOCEANCEN  had  two  distinct  requirements  for 
their  command  information  management  system.  First,  they  had  a  list  of  routine  items 
on  which  they  wanted  up-to-the-minute  information.  These  items  centered  on  budget 
status  and  equipment  accountability  (plant  property).  The  managers  were  easily  able  to 
describe  these  information  requirements. 

The  second  requirement  was  the  need  for  information  to  meet  future 
management  changes.  The  Navy  is  changing  drastically  and  rapidly  and  it  is  difficult  to 
anticipate  what  that  information  would  be.  The  biggest  area  of  change  is  the  budget 
process  within  with  the  Department  of  Defense’s  (DOD)  current  financial  management 
system.  The  budget  process  procures  money  for  the  Department  of  Defense  from 
Congress,  and  determines  a  command’s  fiscal  processes  and  policies.  If  the  budget 
process  is  changed,  a  new  set  of  procedures  is  required. 
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Not  knowing  the  future,  most  managers  agree  they  need  a  database  containing 
information  concerning  the  daily  operations  of  FLENUMOCEANCEN  and  the  work 
output  production.  This  data  will  be  manipulated  as  required  to  develop  information 
concerning  the  real  costs  of  operating  FLENUMOCEANCEN  and  producing  work 
outputs.  The  managers  desired  an  easy-to-leam  ad  hoc  query  language  such  as 
Structured  Query  Language  (SQL)  [Ref.  l:pp.  175-205].  Many  managers  are  already 
familiar  with  the  capabilities  of  SQL  and  feel  a  brief  training  course  is  all  they  need  to 
become  productive. 

2.  The  Employees 

The  needs  of  the  employees  are  different  from  the  managers.  They  want  help 
coping  with  their  daily  tasks.  There  was  much  discussion  concerning  the  possibility  of 
eliminating  the  paperwork  flow  between  departments  and  divisions.  Where  paperwork 
could  not  be  eliminated,  they  want  assistance  filling  out  the  forms.  The  employees  want 
reference  information  on-line  allowing  copies  of  reports  and  instructions  to  be  discarded. 

The  employees  also  feel  they  can  benefit  from  the  flexibility  of  SQL.  While 
they  do  not  envision  using  SQL  frequently  for  the  performance  of  daily  tasks,  they  felt 
managers  should  retrieve  information  themselves,  thereby  freeing  the  employees  from 
some  time-consuming  research  tasks. 

The  third  requirement  of  the  employees  is  the  most  critical.  The  database  and 
applications  have  to  provide  positive  feedback.  Several  existing  database  systems  do  not 
provide  any  feedback-transactions  are  entered  into  the  database  and  disappear. 
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Employees  maintain  two  set  of  records,  one  on  the  computer  and  a  second  in  a  log  book. 
Any  developed  system  must  be  accepted  by  the  employees  as  efficient. 


B.  THE  INTERVIEWS 

After  the  first  few  interviews,  it  was  obvious  the  personnel  at 
FLENUMOCEANCEN  had  varying  degrees  of  knowledge  of  computer  systems  in 
general  and  databases  in  particular.  A  brief  tutorial  was  prepared  to  help  educate  these 
personnel.  The  tutorial  contained  an  example  of  a  check-in  process  and  a  description  of 
the  data  modeling  process.  Entity  relationship  diagrams  and  relational  schema  diagrams 
were  explained.  The  tutorial  was  distributed  to  personnel  before  their  interview. 

Some  personnel  required  more  than  one  interview.  The  first  interview  was  spent 
reviewing  the  tutorial  and  generating  some  starting  points.  The  succeeding  interviews 
were  used  to  gather  ideas  and  requirements  for  this  project. 

FLENUMOCEANCEN  personnel  were  excited  by  the  idea  of  sharing  information 
between  divisions.  The  best  ideas  concerning  a  department  frequently  came  from  outside 
the  department.  Department  personnel  were  surprised  to  discover  their  contemporaries 
felt  their  department  was  providing  untimely  information. 

There  was  also  concern  about  the  ability  of  appropriate  security  procedures 
protecting  privacy  act  and  sensitive  data.  These  concerns  determined  if  an  administrative 
or  management  function  would  be  included  in  the  database. 
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C.  EXISTING  DATABASES 

Many  areas  considered  for  this  project  have  some  form  of  single  user  database 
already  in  operation.  The  most  popular  is  personnel,  accounting  and  plant  property 
databases.  Several  other  databases  are  maintained  in  spreadsheets  and  word  processors. 

FLENUMOCEANCEN  established  standardized  COTS  packages  for  employee  use. 
The  administrative  databases  use  dBASE‘  IV  software.  Lotus  1-2-3^  is  the  spreadsheet 
software  and  Wordstar^  is  used  for  word  processing.  FLENUMOCEANCEN  recently 
implemented  a  LAN  and  a  calendar  package  containing  information  concerning 
employees’  daily  schedules.  Typical  of  most  shore  commands,  FLENUMOCEANCEN 
is  experiencing  problems  with  the  current  systems.  The  databases  were  developed  by 
individuals  who  had  little  formal  or  practical  training  in  database  design.  Often,  the 
original  programmer  had  transferred  and  current  personnel  are  "stuck"  with  a  system 
which  only  partially  meets  their  needs.  None  of  the  databases  are  designed  to  be  shared 
on  a  LAN. 

The  focus  in  these  early  databases  was  on  the  application  rather  than  on  the  data. 
Some  of  these  relational  databases  do  not  meet  the  requirement  of  the  first  normal  form 
[Ref.  l:p.  373],  which  is  the  minimum  format  required  to  categorize  a  database  as 
relational.  Many  older  systems  began  as  dBASE  II  databases  and  were  "patched  up"  as 
each  succeeding  version  of  dBASE  was  released. 

‘dBASE  is  a  registered  trademark  of  Borland  International,  Inc. 

^Lotus  1-2-3  is  a  registered  trademark  of  Lotus  Development  Corporation. 

^Wordstar  is  a  registered  trademark  of  Wordstar  International. 
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While  there  are  many  problems  with  the  existing  databases,  it  is  important  to  note 
these  databases  met  an  important  need  when  developed.  They  provided  information  to 
someone  who  needed  it.  In  the  short-run  they  were  very  useful. 

D.  FUNCTIONAL  AREAS 

Almost  every  administrative  and  operational  function  is  proposed  for  inclusion  in 
the  database.  Two  criteria  are  established  to  control  the  scope  of  the  database.  First, 
the  data  has  to  be  something  of  interest  to  more  than  one  department.  Second,  the  data 
must  have  a  sponsor-someone  willing  to  maintain  the  data.  The  first  criteria  is 
occasionally  relaxed  when  collecting  data  required  for  a  replacement  financial 
management  system. 

The  following  areas  are  included  in  the  database  design: 

•  Personnel:  employees,  training,  visitors,  awards,  security  access,  work  schedules, 
employee  qualifications,  employee  specialties/resources 

•  General  administration:  correspondence,  logs,  instructions,  plans  of  the  week, 
plans  of  action 

•  Property  and  facilities:  major  property,  minor  property,  other  property  (manuals, 
tapes,  etc.),  buildings,  work  requests 

•  Financial  management:  contractors,  customers,  products,  budgets,  supplies, 
inventories 

These  functions  are  chosen  for  their  concern  to  most  shore  commands  with  the 
possible  exception  of  the  contractor  area.  The  data  in  these  areas  are  of  interest  to  more 
than  one  department  and  currently  being  maintained  by  someone  in  the  command. 
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Several  areas  are  not  included.  The  first  area  is  categorized  as  not  of  general 
interest  in  the  command.  The  second  area  contains  personnel  data  such  as  punitive 
records.  This  information  is  considered  too  sensitive  to  contain  in  this  type  of  COTS, 
multi-user  database. 

An  additional  concern  is  the  legal  requirement  to  obtain  a  signature  on  documents. 
Any  document  requiring  a  signature  can  be  augmented  with  the  database,  but  not 
replaced.  For  example,  FLENUMOCEANCEN  uses  a  locally  designed  work  sheet  to 
begin  processing  travel  orders.  This  work  sheet  could  be  eliminated  and  replaced  with 
a  travel  application  in  the  database.  The  database  could  then  prepare  the  actual  travel 
orders  requiring  appropriate  signature  for  completion. 
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in.  THE  DESIGN  AND  IMPLEMENTATION  MODELS 


This  chapter  briefly  discusses  the  advantages  of  the  enhanced  entity  relationship 
(EER)  model  as  a  database  design  model  and  gives  steps  necessary  to  convert  the  EER 
model  to  the  relational  model  for  implementation. 

A.  THE  ENHANCED  ENTITY  RELATIONSHIP  MODEL 

The  enhanced  entity  relationship  model  [Ref  l:p.  410]  was  chosen  as  the  design 
model.  The  EER  model  is  a  high-level  conceptual  data  model.  This  model  allows  a 
great  deal  of  information  to  be  displayed  in  an  enhanced  entity  relationship  diagram 
(EERD).  These  diagrams  can  be  used  by  the  database  designer  and  the  users  to  diagram 
the  mini-world  being  considered.  The  EER  model  is  not  an  implementation  model. 
There  are  no  commercial  database  products  available  which  implement  the  EER  model 
directly  [Ref.  l:p.  37], 

To  illustrate  the  flexibility  of  the  EER  model  and  diagram,  consider  figure  1,  a 
mini-world  where  shore  commands  may  hire  employees.  Employees  must  work  for  some 
shore  command,  but  only  one.  Each  employee  must  be  assigned  a  billet.  The  employees 
must  be  either  civil  service  employees  or  military  employees.  The  shore  command  has 
a  name,  a  unit  identification  code  (UIC)  and  a  commanding  officer.  Each  UIC  and 
commanding  officer  is  unique.  Each  employee  has  a  last  name,  a  unique  social  security 
number  (SSN)  and  one  or  more  office  phone  numbers.  Civil  service  employees  have  a 
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Figure  1.  HER  Diagrams:  An  Example 


civil  service  series  number  and  a  grade/step.  Military  members  have  a  rank  and  a 
planned  rotation  date  (PRD).  A  billet  has  a  unique  billet  sequence  code  (BSC)  and  a 
title.  Each  employee  may  have  several  family  members.  The  family  member  has  a  first 
name,  a  date  of  birth  (DOB)  and  a  ^x.  Each  employee  is  supervised  by  another 
employee.  Employees  may  attend  training  courses.  Each  course  is  attended  by  several 
employees.  Courses  have  an  identification  code  and  a  cost. 
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Figure  2  contains  the  symbols  used  in  EER  diagram  construction  [Ref.  l:pp.  57, 
412].  While  the  EERD  may  be  intuitive  to  most  users,  the  following  definitions  may  be 
helpful  to  correctly  interpret  the  EERD: 


•  Entity  type:  a  group  of  things  in  the  real  world  with  an  independent  existence  [Ref 
1:  p.  40].  Examples  of  entities  are  COMMAND  and  EMPLOYEE.  Entity  types 
are  represented  by  rectangles. 

•  Weak  Entity  Type:  an  entity  type  without  a  key  attribute  of  its  own  [Ref.  1:  p. 
52].  The  FAMILY  MEMBER  entity  type  is  a  weak  entity  type  in  figure  1.  Weak 
entity  types  are  represented  by  double  rectangles.  The  weak  entity  type  only  has 
a  partial  key,  the  primary  key  of  the  owner  entity  type  is  also  needed.  The  partial 
key  is  represented  by  a  dashed  underscore. 

•  Attribute:  "a  property  of  the  entity  describing  the  entity"  [Ref  1:  p.  40]. 
Examples  of  simple  attributes  for  the  EMPLOYEE  entity  are  last  name,  social 
security  number  and  office  phone  number.  A  key  attribute  is  an  attribute  or  a 
group  of  attributes  uniquely  identifying  each  entity.  Attributes  are  represented  by 
ovals.  Key  attributes  are  represented  by  a  solid  underscore.  Partial  keys  are 
represented  by  a  dashed  underscore. 

•  Multi-Valued  Attribute:  an  attribute  having  multiple  values  for  a  single  entity  [Ref 
1  :p.  41].  The  attribute  office  phone  number  might  be  multi-valued  if  there  is  more 
than  one  number  available  to  an  office.  Multi-valued  attributes  are  represented  by 
double  ovals. 

•  Relationship  type:  "a  set  of  associations  among  entities"  [Ref  l:p.  46].  A 
command  employs  employees.  The  COMMAND  entity  is  related  to  the 
EMPLOYEE  entity  through  the  employs  relationship.  Relationship  types  are 
usually  described  with  verbs.  Relationship  types  are  represented  by  diamonds. 

•  Identifying  Relationship:  a  relationship  type  used  to  link  a  weak  entity  type  to  its 
owner  [Ref.  l:p.  52]  The  has  family  relationship  type  is  an  identifying 
relationship  in  figure  1 .  Identifying  relationships-types  are  represented  by  double 
diamonds. 

•  Recursive  Relationship:  a  relationship  where  an  entity  type  participates  in  a 
relationship  more  than  once  in  different  roles  [Ref.  l:p.  49]  The  supervision 
relationship  is  recursive.  An  employee  is  supervised  by  another  employee.  A 
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recursive  relationship  type  can  be  recognized  by  the  "circle”  from  the  entity  type 
to  the  relationship  type  back  to  the  original  entity  type. 

•  ISA  Relationship:  a  special  relationship  for  creating  subclasses  of  entities  [Ref  l:p. 
410].  The  EMPLOYEE  entity  type  is  the  superclass.  Each  employee  is  either  a 
civil  service  employee  or  a  military  employee.  CIVIL  SERVICE  and  MILITARY 
are  subclasses.  An  ISA  relationship  type  is  represented  by  a  triangle. 

•  Participation  Constraint:  "the  existence  of  an  entity  depends  on  its  being  related 
to  another  entity  via  the  relationship  type"  [Ref.  l:p.  50].  In  figure  1, 
EMPLOYEE  participates  totally  in  the  employs  relationship.  Every  employee  must 
be  employed  by  a  command.  The  COMMAND  entity  only  participates  partially 
in  the  relationship.  Each  command  may  not  employ  employees.  Partial 
participation  is  represented  by  a  single  line  between  the  entity  type  and  the 
relationship  type;  total  participation  is  represented  by  a  double  line. 

•  Cardinality  Ratio:  "the  number  of  relationship  instances  that  an  entity  can 
participate  in"  [Ref.  l:p.  50].  The  three  types  are  one-to-one  (1:1),  one-to-many 
(1:N)  and  many-to-many  (M:N).  In  figure  1,  the  COMMAND: EMPLOYEE 
relationship  is  an  example  of  a  1  :N  relationship.  One  command  may  employ  many 
employees.  An  example  of  a  1:1  relationship  is  EMPLOYEE: BILLET.  One 
employee  is  assigned  to  one  billet.  COURSE: EMPLOYEE  is  an  example  of  a 
M:N  relationship.  A  course  is  taken  by  many  employees  and  employees  take  many 
courses. 


j  Entity  Type 
Weak  Entity  Type 
Relationship  Type 


Identifying 
Relationship  Type 


Attribute 

Multi-Valued 

Attribute 

Primary  Key 
Partial  Key 


Partial 

Participation 

Total 

Participation 
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Relationship  Type 


Cardinality  Ratio 
1  to  Many 


Figure  2.  EER  Diagram  Notation 
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B.  THE  RELATIONAL  MODEL 


Since  the  EER  model  is  not  currently  available  as  a  COTS  product,  it  is  necessary 
to  translate  or  map  the  EER  model  to  an  implementation  model.  The  relational  model 
was  chosen  for  this  project  because  of  its  flexibility,  availability  and  cost.  One  of  the 
benefits  of  the  EER  model  is  that  it  can  be  mapped  quickly  and  easily  to  the  relational 
model.  Figures  3  and  4  illustrate  the  mapping  process.  There  are  eight  steps  to  the 
mapping  process  [Ref.  l:pp.  329-331,  427-428]: 


•  Step  1 :  For  each  regular  entity  type,  create  a  relation  containing  all  the  simple 
attributes  of  the  entity  type.  Assign  a  unique  attribute  or  unique  group  of  attributes 
as  the  primary  key.  Underscore  the  primary  key.  Identify  any  other  attributes 
which  could  serve  as  candidate  keys  (c.k.).  Figure  3,  step  1  shows  four  relations, 
COMMAND,  EMPLOYEE,  BILLET  and  COURSE  that  were  created. 

•  Step  2:  For  each  weak  entity  type,  create  a  relation  containing  all  the  simple 
attributes  of  the  entity  type.  Also  include  as  a  foreign  key  (f.k.),  the  key 
attribute(s)  of  the  owner  entity  type.  Figure  3,  step  2  shows  the  addition  of  the 
FAMILY  MEMBER  relation  with  the  inclusion  of  the  SSN  attribute  from  the 
EMPLOY"eE  relation. 

•  Step  3:  For  each  binary  1:1  relationship,  identify  the  two  relationships  involved 
and  add  the  primary  key  of  one  relation  as  a  foreign  key  in  the  other.  Figure  3, 
step  3  shows  that  the  SSN  attribute  from  EMPLOYEE  was  included  in  the  BILLET 
relation. 

•  Step  4;  For  each  non-weak  binary  1:N  relationship,  identify  the  relationship  on  the 
1  side  and  include  its  primary  key  as  a  foreign  key  in  the  relationship  on  the  N 
side.  Figure  3,  step  4  shows  the  UIC  attribute  from  the  COMMAND  relationship 
included  in  the  EMPLOYEE  relation.  Since  the  supervision  relationship  is 
recursive,  the  EMPLOYEE  relation  also  includes  a  new  attribute  called  Boss_SSN 
which  represents  the  supervisor’s  SSN  as  a  foreign  key  which  refers  back  to  the 
SSN  in  the  same  EMPLOYEE  relation. 

•  Step  5:  For  each  binary  M:N  relationship,  create  a  new  relation  and  include  the 
primary  keys  from  both  of  the  relations  in  the  new  relation.  Also  include  any 
attributes  of  the  relationship  in  the  new  relation.  In  figure  3,  step  5  the  new 
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relation  EMP-COURSE  is  created.  It’s  primary  key  is  the  combination  of  the  SSN 
and  CID  attributes  from  the  EMPLOYEE  and  COURSE  relations.  The  attribute 
Date  was  added  to  the  new  relation. 

•  Step  6:  For  each  multi-valued  attribute,  create  a  new  relation  including  the 
primary  key  of  the  entity  and  the  multi-valued  attribute.  In  figure  4,  step  6  a  new 
relation  EMP-PHONE  was  created  with  the  attributes  Office_Phone  and  SSN.  The 
primary  key  for  the  EMP-PHONE  relation  is  a  combination  of  both  attributes. 

•  Step  7;  For  each  n-ary  relationship,  create  a  new  relationship  and  include  as 
foreign  keys  the  primary  keys  of  each  relation  in  the  n-ary  relationship.  This  step 
is  not  necessary  in  this  example  because  this  mini-world  does  not  contain  a 
relationship  with  more  than  two  entity  types  participating, 

•  Step  8:  For  each  subclass  ISA  entity,  create  a  relation  and  include  as  the  foreign 
and  primary  key,  the  primary  key  of  the  superclass  encity  type.  In  figure  4,  step 
8  the  CIVIL  SERVICE  and  MILITARY  relations  were  created. 


Elmasri  and  Navathe  [Ref.  l:pp.  427-428]  propose  several  different  options  for 
completing  step  8.  The  method  used  in  step  8  of  this  example  provides  relations  that 
duplicate  only  the  primary  key  in  the  relations  representing  the  subclass  entity  types. 
The  other  options  duplicate  more  than  just  the  primary  key  or  result  in  relations  having 
many  empty  attributes.  This  option  is  appropriate  for  this  type  of  superclass/subclass 
relationship  type  [Ref.  l:p.  428]. 

Upon  completion  of  these  eight  steps,  the  relations  are  in  the  1st  normal  form 
(INF)  of  the  relational  model  [Ref  l:p.  373],  Normalization  is  "The  process  of 
determining  the  correct  location  and  function  for  each  attribute  in  order  to  correctly 
formulate  the  relational  schema."  [Ref  2;p.  56]  While  eight  norma!  forms  are  defined 
for  the  relational  model,  it  is  not  always  necessary  or  desirable  to  normalize  to  the 
highest  possible  form  [Ref  l:pp.  372].  The  higher  normal  forms  are  difficult  to 
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understand  and  divide  the  database  into  many  small  relations  causing  serious  performance 
problems.  The  fourth  level,  Boyce-Codd  Normal  Form  (BCNF)  is  considered  a  good 
compromise  [Ref.  l:p.  372].  The  example  in  step  8  of  figure  3  also  happens  to  be  in 
BCNF,  without  any  additional  work. 
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IV.  THE  BASIC  MODEL 


This  chapter  presents  the  EER  model  created  during  this  project.  The  chapter 
outlines  the  refinement  process  and  discusses  methods  to  modify  the  model  for 
implementation  at  different  commands. 

A.  THE  CONCEPTUAL  SCHEMA  DESIGN  PROCESS 

After  the  interviews  and  review  of  the  existing  systems,  an  initial  EER  model  was 
created.  The  model  underwent  a  refining  process  resulting  in  the  model  contained  in 
Appendix  A.  When  looking  at  the  command  as  a  whole,  it  became  obvious  that  entity 
types,  considered  unique  by  division  personnel,  were  in  fact  minor  variations  of  one 
entity  type.  For  example,  the  office  supplies,  the  PC  software  supplies  and  the  spare 
parts  inventory  were  all  condensed  into  the  INVENTORY  entity  type.  This  first  major 
refinement  involved  consolidating  these  separate  entity  types  into  broader  entity  types. 
This  process  cut  the  number  of  entity  types  by  approximately  30  percent. 

At  this  point,  the  model  had  three  main  focal  points.  The  EMPLOYEE, 
ORGANIZATION  and  BUDGET  entity  types  were  hubs  around  which  the  other  entity 
types  were  arrayed.  A  fourth  area,  general  administration,  did  not  have  a  hub  but  was 
a  recognizable  group  about  the  ORGANIZATION  entity  type. 

After  the  initial  refinement,  the  model  was  reviewed  by  FLENUMOCEANCEN 
representatives  and  officers  that  had  served  at  different  types  of  Naval  shore  commands. 
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It  became  obvious  that  the  model  did  not  adequately  represent  commands  other  than 
FLENUMOCEANCEN.  To  make  the  model  functional  for  other  commands,  it  was 
necessary  to  remove  many  of  the  relationship  types  between  the  entity  types.  For 
example,  at  some  commands  an  employee  may  not  attend  a  training  course  unless  the 
course  is  listed  on  the  employee’s  individual  development  plan  (IDP).  This  would  create 
a  ternary  relationship  between  EMPLOYEE,  COURSE  and  INDIVIDUAL 
DEVELOPMENT  PLAN.  At  other  commands,  the  IDP  is  only  a  guiding  document  and 
is  not  meant  to  restrict  an  employee’s  course  selection. 

This  second  refinement  reduced  the  number  of  relationship  types  by  40  percent. 
The  resulting  model  lost  its  BUDGET  hub  and  was  converted  to  a  broad  area  concerning 
the  fiscal  management  activities  of  a  command.  The  ORGANIZATION  and 
EMPLOYEE  hubs  remained. 

B.  THE  BASIC  MODEL 

The  refinement  process  created  a  model  minimally  acceptable  to  all  the 
representatives  but  insufficient  to  meet  any  one  representative’s  needs.  The  fiscal  area 
created  the  most  dissension  among  the  officers.  The  financial  management  of  a 
command  is  guided  by  many  regulations  but  each  command  has  implemented  varying 
procedures  and  policies  for  complying  with  these  regulations.  For  example,  the 
PHONE  CALL  entity  type  represents  the  long-distance  phone  calls  made  by  the 
organization’s  employees.  These  calls  must  be  accounted  for  upon  receipt  of  the  phone 
bill.  At  some  commands  each  phone  call  is  considered  an  expenditure  against  the 


department’s  budget,  thereby  creating  a  relationship  between  PHONE  CALL  and 
EXPENDITURE.  However,  at  large  commands,  the  phone  calls  are  certified  by  the 
department,  but  are  paid  out  of  a  central  account  whose  budget  is  not  retained  at  the 
lower  level. 

The  differences  in  procedures  could  usually  be  traced  to  the  size  of  the  command. 
The  large  shore  commands  have  a  high  percentage  of  civilian  personnel  and  non- 
traditional  chain  of  command  structures.  At  these  commands,  the  loosest  form  of  the 
model  is  necessary.  At  the  smaller  commands  with  a  traditional  chain  of  command 
structure,  a  tighter  model  may  be  implemented.  None  of  the  representatives  agree  upon 
the  different  attributes  which  should  be  associated  with  each  entity  type. 

The  basic  model  is  diagrammed  in  figures  6  through  7  in  Appendix  A.  The  model 
is  divided  into  four  sections  following  the  four  general  functional  areas: 

•  Section  1:  Personnel 

•  Section  2:  Facilities  and  property 

•  Section  3;  Financial  management 

•  Section  4;  General  administration 

Appendix  B  is  a  data  dictionary  containing  an  alphabetical  list  of  the  entity  types  and  a 
brief  description  of  the  entity  types. 
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C.  CUSTOMIZING  THE  MODEL 


The  basic  model  may  be  mapped  to  the  relational  model  for  implementation.  The 
basic  model  is  very  "loose"  and  represents  those  commands  having  a  non-traditional 
chain  of  command  structure.  The  traditional  responsibilities  of  the  commanding  officer 
in  this  type  of  command  are  delegated  to  several  individuals  due  to  the  size  of  the 
command.  This  structure  is  typical  of  the  large  commands  in  Washington,  Norfolk,  San 
Diego,  Pearl  Harbor,  etc.  The  divisions  in  these  commands  may  contain  several  hundred 
people  and  are  usually  divided  into  smaller  units  for  daily  operations.  These  very  large 
commands  require  the  most  flexible  model  for  their  database.  The  database  is  most 
useful  at  the  smaller  working  group  level. 

A  medium-sized  command  with  a  traditional  chain  of  command  structure  would 
benefit  from  a  "tighter"  version  of  the  basic  model.  This  command  could  modify  the 
model  to  include  more  relationship  types  between  the  entity  types  such  as  the  phone  bill 
example  above.  Personalizing  the  model  allows  the  command  to  accurately  represent 
their  particular  situation. 

Customizing  the  basic  model  involves  four  steps.  First,  examine  the  entity  types 
and  relationship  types  in  the  basic  model.  Do  they  generally  match  the  procedures  at 
your  command?  Make  any  changes  as  appropriate.  Second,  begin  adding  attributes  to 
the  entities.  This  may  not  be  straightforward.  For  example,  where  would  an  office 
phone  number  attribute  belong?  Some  commands  have  one  phone  number  for  each 
division  and  the  attribute  should  belong  to  the  ORGANIZATION  entity  type.  Some 
commands  have  single-line  phones  in  each  office.  In  this  case,  the  phone  number 
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attribute  would  belong  to  the  FACILITY  entity  type.  At  other  commands,  the  phone 
number  is  stored  in  the  phone  itself.  As  personnel  move  from  office-to-office  they  take 
their  phone  and  phone  number  with  them.  The  EMPLOYEE  entity  type  should  be  used 
in  this  situation. 

After  the  attributes  are  added,  the  third  step  is  to  review  the  model.  Check  each 
entity  type  and  relationship  type  to  ensure  they  accurately  represent  your  situation. 
Fourth,  add  any  additional  relationship  types  to  "tighten"  the  model.  Consider  the  new 
relationship  types  carefully,  for  there  is  a  trade-off.  Additional  relationship  types  may 
result  in  additional  relations  which  will  increase  the  complexity  of  the  database  and  may 
decrease  performance  [Ref.  l:p.  372]. 
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V.  DATABASE  ADMINISTRATION  AND  SECURITY  CONSIDERATIONS 


Chapter  V  discusses  some  of  the  policy  and  operational  considerations  that  must 
be  thought  about  before  a  multi-user  database  is  implemented. 

A.  DATABASE  ADMINISTRATOR  FUNCTIONS 

While  this  database  is  not  exceptionally  large,  it  will  be  used  by  personnel  with 
varying  degrees  of  database  expertise.  Once  the  database  is  complete  it  will  be  necessary 
for  an  individual  or  group  to  have  database  administrator  (DBA)  responsibilities.  These 
responsibilities  concern  the  smooth  daily  operation  of  the  database.  The  DBA  will  be 
responsible  for  making  backup  copies  of  the  database,  granting  access  to  the  database  and 
generally  monitoring  the  database  for  problems. 

The  individual  assigned  the  DBA  responsibilities  should  be  knowledgeable  about 
database  practices  and  procedures  in  general  and  with  the  capabilities  of  the  relational 
database  management  system  (RDBMS)  used  to  implement  the  database.  The  DBA 
should  interact  easily  with  users  from  different  departments  and  different  levels  in  the 
chain  of  command.  The  DBA’s  position  in  the  chain  of  command  should  allow  the 
impartial  performance  of  their  duties. 

The  DBA  responsibilities  for  this  database  should  not  require  full-time  personnel. 
The  exact  amount  of  time  spent  daily  on  the  DBA  functions  will  depend  upon  several 
variables.  Initially,  the  procedures  used  to  convert  the  old  single-user  databases  to  the 
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new  database  will  have  a  dramatic  affect  on  the  time  required  to  monitor  the  database. 
Old  single-user  applications  "patched  up"  to  function  in  the  new  system  will  require  a 
great  deal  of  DBA  attention.  Clean  applications  written  by  experienced  personnel  will 
require  less  intervention  by  the  DBA. 

The  individual’s  database  experience  also  will  greatly  affect  the  time  needed  to 
administrate  the  database,  e.g.,  a  knowledgeable  individual  might  require  only  two  hours 
a  day  to  perform  the  DBA  functions  while  a  less  experienced  person  may  require  four 
or  more  hours. 

B.  DATABASE  SECURITY 

The  security  of  the  database  is  one  topic  that  all  the  interviewees  could  agree  upon. 
The  personnel  data  contained  in  the  database  is  subject  to  privacy  act  restrictions  and  the 
financial  management  data  is  sensitive.  Much  of  the  data  could  be  made  available  for 
general  viewing  by  employees,  but  modification  and  deletion  of  the  data  is  restricted. 

The  security  features  of  the  database  depend  primarily  upon  the  RDBMS  package. 
COTS  packages  vary  widely  in  capabilities.  Access  to  data  can  be  controlled  through 
the  multi-level  applications  development,  but  will  not  affect  the  individuals  who  have 
access  to  the  data  manipulation  language,  such  as  SQL. 

First,  the  RDBMS  should  have  a  user  identification  and  password  system.  The 
Department  of  Defense  and  the  Department  of  the  Navy  (DON)  have  extensive  and 
explicit  requirements  for  password  systems  [Ref.  3].  These  regulations  are  usually 
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supplemented  by  local  command  policy.  The  RDBMS  should  support  all  levels  of 
regulations  and  policies. 

Second,  the  RDBMS  security  system  should  allow  the  DBA  to  restrict  access  to  the 
database  by  table,  column  and  row.  The  restrictions  should  include  insert,  modify, 
delete  and  view  functions.  For  example,  all  users  should  have  view  access  to  the  plan 
of  the  week.  Only  certain  users  might  be  allowed  to  insert  new  budget  items  while  other 
users  may  be  allowed  to  modify  the  cost  attribute  for  the  item.  The  combinations  of 
access  to  the  various  entities  are  large  and  require  the  command  to  make  some  policy 
decisions. 

Third,  the  database  should  have  a  mechanism  for  back-tracking  transactions  and 
"rolling  back"  the  database  in  case  of  problems  [Ref.  l:p.  542],  Each  transaction  must 
be  traced  to  a  specific  user. 

Fourth,  the  database  files  should  be  protected.  If  a  user  can  access  the  files  from 
the  operating  system,  the  first  three  security  procedures  are  useless.  Many  COTS 
RDBMS  packages  store  the  database  in  easy-to-access  ASCII  format. 

Another  area  for  consideration  is  the  relationship  between  the  RDBMS  security  and 
the  network  security.  Perhaps  the  network  can  pass  user  identifications  and  passwords 
to  the  DBMS.  This  may  supplement  the  existing  system  by  providing  another  layer  of 
security. 
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VI.  PROTOTYPE 


Chapter  VI  provides  an  overview  of  the  single-user  prototype  developed  as  part  of 
this  project.  Positive  and  negative  aspects  of  the  database  management  system  software 
are  discussed. 

A.  THE  DATABASE  MANAGEMENT  SYSTEM 

R.BASE  3.1C'‘  from  Microrim  was  used  to  implement  the  prototype.  R:BASE 
3. 1C  was  chosen  because  it  meets  the  American  National  Standards  Institute  (ANSI) 
Level  2  SQL  standard  [Ref.  4;p.  321].  It  is  readily  available  on  the  commercial  market, 
though  it  is  not  as  widely  known  as  some  other  RDBMS  packages.  R:BASE  can  be 
implemented  for  multiple  users  on  a  LAN  but  the  prototype  was  developed  only  for  a 
single-user. 

RrBASE  3. 1C  also  contains  several  features  that  make  it  an  excellent  choice  for  this 
prototype.  It  contains  a  data  dictionary  and  an  extensive  set  of  aggregate  functions  not 
included  in  the  SQL  standard.  RrBASE  3. 1C  has  transaction  processing  and  rollback 
features.  The  screen  and  report  generators  are  easy  to  use  and  sophisticated. 

RrBASE  3. 1C  uses  SQL  to  create  rules  regulating  data  entry  in  the  database  [Ref. 
4rpp.  256-260].  These  rules  are  variations  of  the  SQL  select  command  [Ref.  Irp.  178]. 
For  example,  if  the  database  contains  a  table  called  STATES  of  the  50  state  abbreviation 

^RrBASE  is  a  registered  trademark  of  Microrim,  Inc. 
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codes  and  a  table  called  CUSTOMER  where  customer  addresses  are  entered,  the 
paraphrased  rule  would  say,  "Add  the  row  to  CUSTOMER  if  the  customer’s  state  code 
is  in  STATES. "  The  flexibility  of  SQL  allows  the  creation  of  very  complex  rules  to  help 
maintain  the  integrity  of  the  database. 

B.  PROTOTYPE  FUNCTIONS 

Appendix  C  contains  an  EERD  of  the  prototype.  The  organization  and  personnel 
hubs  were  chosen  as  the  basic  starting  points  for  the  prototype.  Most  of  the  personnel 
and  general  administration  areas  that  were  included  in  the  prototype  were  chosen  because 
they  did  not  currently  have  any  automated  support.  Their  inclusion  was  needed  to  help 
those  users  envision  the  possibilities  of  full  implementation.  The  property  area  was 
included  because  all  the  department  heads  felt  it  needed  immediate  attention. 

The  developed  applications  were  very  basic.  The  ability  to  add,  edit  and  delete 
records  using  an  intuitive  menu  system  was  the  primary  function.  The  reports  developed 
included  listing  of  property,  personnel  recall  bills,  plans  of  action  and  distribution  labels 
for  incoming  correspondence. 

C.  ASSIMILATING  EXISTING  DATA 

Whenever  possible,  data  from  existing  databases  were  incorporated  into  the 
prototype.  The  existing  data  was  contained  in  dBASE  IV,  Lotus  1-2-3  and  various  word 
processors.  Each  of  these  programs  could  output  the  data  to  an  ASCII  file.  If  the  data 
needed  drastic  manipulation,  it  was  imported  to  a  word  processor,  edited  and  output 
again  to  an  ASCII  file.  R:BASE  does  not  store  the  data  in  separate  ASCII  files  but 
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contains  an  import  feature  [Ref.  5:p.  8-25]  that  allowed  the  data  to  be  loaded  into  the 
database. 

D.  LESSONS  LEARNED 

R:BASE  provided  an  excellent  tool  for  developing  the  prototype  database.  The 
database  was  created  in  only  one  hour  while  the  applications  required  approximately  25 
hours.  The  screen  and  report  generators  were  outstanding.  The  data  dictionary  was 
useful  but  limited  in  the  amount  of  space  allowed  for  descriptions. 

The  R-.BASE  security  system  could  control  access  to  tables  and  columns,  but  not 
to  rows.  This  means  if  all  the  departments’  budgets  are  stored  in  one  table  with  an 
attribute  to  identify  the  department,  there  is  no  way  to  use  this  attribute  to  restrict  a 
department  head  from  accessing  other  departments’  budgets  unless  it  is  through  an 
application  program. 

R:BASE  can  only  link  a  maximum  of  five  tables  when  creating  a  view.  There  was 
a  noticeable  delay  in  response  time  when  SQL  was  used  to  join  more  than  three  tables 
in  a  query. 

An  additional  concern  was  the  speed  of  the  RDBMS.  R:BASE’s  performance  was 
unacceptable  on  a  personal  computer  with  an  80286  processor  but  provided  a  response 
time  of  two  or  three  seconds  with  an  80386  processor.  This  might  not  be  a  concern  on 
a  multi-user  system  as  it  is  unlikely  that  an  80286  processor  would  be  used  as  a  server. 
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VU.  CONCLUSIONS 


This  project  is  considered  the  first  step  for  developing  the  requirements  in  a  multi¬ 
user  relational  database  at  FLENUMOCEANCEN  that  can  be  accessed  via  a  LAN.  This 
is  the  first  time  that  the  functional  management  relationships  of  the  command  have  been 
viewed  as  a  whole  and  the  conceptual  schema  for  a  database  designed  for  the  command. 
The  management  functions  outlined  in  section  D  of  Chapter  II  are  of  concern  to  every 
shore  command  and  are  suited  for  implementation  in  a  multi-user,  relational  database. 
Most  commands  will  have  additional  functions  that  should  be  included,  depending  upon 
the  command’s  mission.  Almost  any  functional  area  can  be  included  in  the  model. 
Areas  containing  extremely  sensitive  personnel  data  and  classified  data  should  not  be 
included;  or  if  included,  must  have  the  appropriate  security  system  for  the  type  of  data 
[Ref.  3]. 

The  model  developed  and  displayed  in  Appendix  A  could  be  used  by  any  command 
as  a  generic  model  for  a  database  design,  but  to  be  truly  effective,  the  model  should  be 
personalized  for  the  command.  Additional  relationship  types  exist  at  most  commands, 
especially  in  the  financial  management  section  of  the  model.  Unfortunately,  it  is  not 
possible  to  create  one  database  and  application  system  that  could  be  used  at  all 
commands.  The  Naval  Computer  and  Telecommunications  Area  Master  Station  Lant 
Detachment  has  created  several  products  under  the  GENUS  name  that  provide 
administrative  functions.  These  products  have  mixed  support  in  the  shore  community. 
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Some  commands  feel  the  GENUS  products  meet  their  needs  while  others  do  not  like  the 
procedures  required  by  GENUS  products. 


Customizing  the  design  may  require  creating  additional  entity  types  and  relationship 
types.  Attributes  must  be  added  to  the  design  in  the  appropriate  location  for  the 
command.  Next  the  customized  EER  model  is  mapped  to  the  relational  model  and 
normalized.  The  design  is  ready  to  be  implemented  in  the  RDBMS.  This  process  will 
require  the  attention  of  a  database  design  professional.  While  both  the  mapping  process 
and  the  normalization  process  have  step'by-step  instructions,  there  are  always  occasions 
when  a  design  decision  must  be  made  between  two  or  more  options.  An  experienced 
database  designer  can  evaluate  the  options  and  choose  the  most  effective  one(s). 

The  primary  benefit  of  a  successful  implementation  of  this  project  is  the  decrease 
in  time  spent  on  administrative  matters  and  the  availability  of  timely  information  to 
support  quick  response  requirements.  The  need  to  support  these  requirements  can  be 
demonstrated  by  two  programs  that  could  dramatically  affect  a  shore  commands 
operations  and  require  the  Navy  to  consider  the  need  for  a  generic  relational 
administrative  database  design  tailored  to  meet  functional  requirements  [Ref.  6].  The 
first  is  lue  unit  costing  proposal  under  which  a  command  would  be  provided  a  set  amount 
of  funding  for  every  product  it  produces.  A  second  proposal  is  the  Defense  Business 
Operating  Fund  (DBOF),  which  is  a  program  where  military  commands  operate  as 
businesses  and  charge  ot.  .r  commands  for  products  and  services.  This  is  currently  how 
the  Industrial  Fund  activities,  such  as  ship  yards,  operate.  DBOF  is  currently  being 
tested  at  several  shore  commands  and  might  apply  to  all  commands  in  the  next  few  years. 
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Both  of  these  initiatives  will  require  a  command  to  have  access  to  its  real  costs  and 
outputs.  Implementation  of  DBOF  will  require  sophisticated  billing  and  accounting 
software  while  unit  costing  will  require  certification  of  outputs.  This  database  design  is 
the  first  step  toward  preparing  for  these  initiatives. 

The  implementation  of  a  multi-user,  relational  database  will  require  the  attention 
of  a  database  administrator  to  function  correctly.  Experienced  database  administrators 
already  have  many  demands  placed  upon  their  time.  This  database  will  be  an  additional 
burden.  Another  cost  is  the  purchase  of  a  sophisticated  COTS  package  to  implement  the 
design  and  training  of  command  personnel  to  use  the  COTS. 

The  basic  model  developed  during  this  project  is  intended  to  provide  a  starting 
point  for  shore  commands.  The  model  can  be  used  to  evaluate  COTS  management 
information  systems  for  their  applicability  to  meet  the  Naval  shore  command’s 
environmental  requirements.  Products  that  cannot  provide  this  minimum  functionality 
are  ineffective  and  will  not  meet  the  needs  of  the  command.  A  tailored  model  can  be 
used  to  establish  specifications  and  design  requirements  for  the  development  a 
command’s  management  information  system. 
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APPENDIX  A 


THE  BASIC  ENHANCED  ENTITY  RELATIONSHIP  MODEL 


This  appendix  contains  the  basic  enhanced  entity  relationship  model  developed 
during  this  thesis. 
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Figure  6.  EBRD  Section  2 
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Figure  8.  EERD  Section  4 
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APPENDIX  B 


THE  ENTITY  TYPE  DESCRIPTIONS 

This  appendix  contains  the  descriptions  of  the  entity  types  developed  for  the  model 
in  Appendix  A.  The  entity  type  codes  are  R  for  regular,  W  for  weak  and  S  for  subclass. 
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Entity  Type  Name 


HERD  Entity 

Section  Type  Description 


ACCESS 

1 

R 

A  type  of  permission  or  authorization  that 
might  be  granted  to  people.  For  example, 
authorization  to  drive  military  vehicles  or 
individuals  who  may  have  access  to  a  room 
or  building. 

ACTIVE  ENLISTED 

1 

S 

An  EMPLOYEE  who  is  an  active  duty 
enlisted  member. 

ACTIVE  OFFICER 

1 

S 

An  EMPLOYEE  who  is  an  active  duty 
officer. 

AWARD 

1 

s 

An  award  or  recognition  that  may  be  given 
to  an  EMPLOYEE  as  a  reward  for 
outstanding  performance. 

BILLET 

1 

R 

A  specific  civilian  or  military  job  or 
position. 

BUDGET 

3 

R 

The  financial  spending  plan  of  a  command. 

COLLATERAL 

DUTY 

1 

R 

An  duty  assignment  given  to  an 
EMPLOYEE  in  addition  to  their  traditional 
duties. 

CONTRACT 

4 

R 

A  legal  document  used  to  purchase  goods  oi 
services. 

CONTRACTOR 

1 

s 

A  PERSON  who  is  employed  under  a 
CONTRACT. 

COURSE 

1 

R 

A  period  of  training. 

CUSTOMER 

3 

R 

Someone  who  receives  service  from  the 
command. 

Entity  Type  Name 

HERD 

Section 

Entity 

Type 

Description 

DISTRIBUTION 

LIST 

4 

R 

A  list  of  EMPLOYEES  who  receive  a  piece 
of  INCOMING  CORRESPONDENCE 
based  upon  its  topic. 

EMPLOYEE 

1 

R 

A  military  or  civil  service  PERSON  who 
works  for  the  ORGANIZATION. 

EVENT 

2 

R 

A  meeting  or  briefing. 

EXPENDITURE 

3 

R 

An  expense  incurred  by  the 
ORGANIZATION. 

FACILITY 

2 

R 

A  base,  building  or  room  under  the 
management  of  the  ORGANIZATION. 

FAMILY  MEMBER 

1 

W 

A  member  of  an  EMPLOYEE’S  family. 

GM 

1 

S 

A  general  management  civil  service 
EMPLOYEE. 

GS 

1 

S 

A  general  service  civil  service 

EMPLOYEE. 

INCOMING 

CORRESPONDENCE 

4 

R 

A  piece  of  mail  or  message  traffic  received 
by  the  ORGANIZATION. 

INDIVIDUAL 

DEVELOPMENT 

PLAN 

1 

R 

A  plan  of  short-  and  long-term  goals  for  an 
EMPLOYEE.  The  plan  usually  contains  a 
list  of  training  COURSES  that  the 
EMPLOYEE  will  take  during  the  next  year. 

INVENTORY 

3 

R 

A  group  of  items  held  in  storage  until 
ne^ed. 

LOG 

4 

R 

A  list  of  events  that  transpired  during  a 
work  shift. 
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Entity  Type  Name 

EERD 

Section 

Entity 

Type 

Description 

MAJOR  PROPERTY 

2 

S 

Property  that  is  classified  by  regulation  as 
major.  U?  ally  property  that  has  a  value 
greater  than  $5,000. 

MINOR  PROPERTY 

2 

S 

Property  that  is  classified  by  regulation  and 
policy  as  minor. 

OFF-SITE 

CONTRACTOR 

1 

S 

A  CONTRACTOR  that  does  not  work  in 
the  ORGANIZATION’S  FACILITY. 

ON-SITE 

CONTRACTOR 

1 

S 

A  CONTRACTOR  that  works  inside  the 
ORGANIZATION’S  FACILITY. 

ORGANIZATION 

1 

R 

A  Naval  command,  department  or  division. 

OTHER  PROPERTY 

2 

S 

PROPERTY  for  which  it  is  necessary  to 
maintain  its  current  location. 

OUTGOING 

CORRESPONDENCE 

4 

R 

Mail  or  message  traffic  that  is  originated  by 
the  ORGANIZATION. 

PERSON 

1 

R 

A  person. 

PHONE  CALL 

1 

R 

A  phone  conversation  held  by  an 
EMPLOYEE.  Usually  longdistance  calls. 

PLAN  OF  THE 

WEEK 

4 

R 

A  weekly  newsletter  published  by  the 
ORGANIZATION. 

POA&M 

4 

R 

A  plan  of  action  to  complete  a  goal. 

PRODUCT 

3 

R 

An  item  that  is  produced  for  a 

CUSTOMER. 

PROPERTY 

2 

R 

Equipment  or  items  that  are  owned  by  the 
ORGANIZATION. 
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Entity  Type  Name 

HERD 

Section 

Entity 

Type 

Description 

QUALIFICATION 

I 

R 

A  skill  that  is  held  by  EMPLOYEES. 

REFERENCE 

4 

R 

An  item  that  is  used  to  hold  information. 
Regulations,  instructions  and  policies  are  all 
REFERENCES. 

SPECIAL 

PURCHASE 

3 

R 

An  item  that  is  not  a  federal  government 
standard  stock  supply. 

STANDARD 

SUPPLY 

3 

R 

Items  that  are  federal  government  standard 
stock  supplies. 

SUPPLY  LIST 

3 

R 

The  federal  government  standard  stock 
supply  list. 

TRAVEL 

1 

R 

A  business  trip  taken  by  an  EMPLOYEE. 

TASK  ORDER 

3 

R 

A  work  order  issued  against  a 

CONTRACT. 

UNFUNDED 

REQUIREMENT 

3 

R 

An  item  or  project  the  ORGANIZATION 
wishes  to  buy  or  complete  that  does  not 
have  funding  in  the  BUDGET. 

VISITOR 

1 

S 

A  PERSON  who  visits  the 
ORGANIZATION. 

WG 

1 

S 

A  wage  grade  civil  service  EMPLOYEE. 

WORK  SCHEDULE 

1 

R 

A  schedule  of  an  EMPLOYEE’S  working 
times. 

WORK  REQUEST 

2 

R 

A  request  to  repair  a  damaged  FACILITY. 
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APPENDIX  C 


THE  PROTOTYPE 

This  appendix  contains  the  enhanced  entity  relationship  model  and  one  possible 
relational  mapping  of  the  prototype  model  developed  for  FLENUMOCEANCEN. 
The  relational  schema  diagrammatic  technique  is  that  used  by  Kroenke  and  Dolan 
[Ref.  7:pp.  167-213].  A  small  number  of  attributes  were  chosen  for  the  prototype: 

•  ORGANIZATION;  Organization  Code,  Organization  Name,  UIC,  Message 
Address,  Street,  City,  State,  Zip 

•  INCOMING  CORRESPONDENCE:  Serial  Number,  Originator,  Standard 
Subject  Identification  Code,  Subject,  Date,  Received  Date 

•  DISTRIBUTION  LIST:  Keyword,  Organization  Code 

•  PLAN  OF  THE  WEEK:  Message,  Start  Message  Date,  Stop  Message  Date,. 
Message  Priority 

•  FACILITY;  Facility  Name,  Facility  Type 

•  PROPERTY:  Serial  Number,  Property  Type,  Cost,  Nomenclature 

•  PERSON:  SSN,  Last  Name,  First  Name,  Middle  Name,  Date  of  Birth 

•  EMPLOYEE:  Office  Phone  Number 

•  VISITOR:  Visit  Start  Date,  Purpose  of  Visit,  Visit  Stop  Date 

•  ACTIVE  OFFICER:  Rank,  Designator 

•  GS:  Series,  Grade,  Step 

•  FAMILY  MEMBER:  First  Name,  Relationship 
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This  EER  diagram  uses  a  different  labeling  convention  to  display  the  cardinality 
ratio  discussed  in  Chapter  III.  The  numbers  in  the  parentheses  represent  the 
minimum  and  maximum  participation  of  the  entity  ♦ype  in  the  relationship  type  [Ref, 
l  ;p.  57].  This  convention  provides  more  information  than  using  the  1,  N  and  M. 

For  example,  in  Figure  9,  an  organization  may  manage  zero  (0)  to  many  (N) 
facilities.  Zero  in  the  minimum  number  of  facilities  an  o’^ganization  may  manage 
with  no  upper  limit  set  on  the  maximum  number  of  facilities  an  organization  may 
manage  (N).  A  facility  must  be  managed  by  one  and  only  one  organization. 
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Figure  9.  The  Prototype  HERD 
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Figure  10.  The  Prototype  Relational  Schema 
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